
that over two-thirds of the nodes have acknowledged the proposal or a timeout limit has
been reached, the validator enters the prevote step.
In the prevote step, the validator verifies two components. First, it verifies that the pro-
posed block is a valid one, by running an external function isBlockV alid = validate(bl ock
h
).
If isBlockV alid = true, then the validator verifies the random number generated by the
proposer. This is performed by first computing the alpha input using function (3.2) then
the validator runs the following verification function:
(isV RF V alid, t
′
h
) = ECV RF _verif y(P
k
, π, m
r
) (3.5)
in which t
′
h
= ECV RF _proof _to_hash(π).
Since each combination of S
k
and m
r
generates a unique proof π, function (3.5) only
returns isVRFValid = true if the proof π (and, in turn, the value t
h
) is calculated in an
honest manner by the proposal. In the last stage, the validator needs to submit its deci-
sion. If both isBlockV alid and isV RF V alid return true and the value t
′
h
is equal to
t
h
, the validator thus will sign, submit a prevote for the proposed block and broadcast
this prevote to the adjacent validators through Gossip protocol. In any other case (e.g.
isV RF V alid returns false), the validator will sign a nil message and broadcast this pre-
vote to the blockchain.
The rest of the block formation will perform similar to Tendermint’s protocol. In the
beginning of the Precommit step, each validator will make a decision based on how many
prevotes that validator has received for the proposed block. If the prevote count is more
than
2
3
of total prevotes for the proposed block, the validator will sign and broadcast a
precommit for that particular block, and lock onto that block, releasing any prior locks in
the progress. If the node had received more than
2
3
of nil prevotes, it will broadcast a nil
precommit, and just unlock any locked block it has locked on before.
At the end of the Precommit step, each node will count the precommits it received
via the Gossip protocol. If there are more than
2
3
of precommits that are not nil for an
acceptable block, the validator will enter Commit step, otherwise it will ready for the next
round.
At the Commit step, the validator will sign and broadcast for the block it must have
received from the proposer, and then it will wait for other commits from other validators
on the blockchain. When
2
3
of the commits have been received, the validator will set the
CommitT ime to the current time, and enter N ewHeight step, ready to build a new block
to the blockchain. The N ewHeight step is a padding step that lasts for a fixed duration,
its purpose is for slow validators to be able to commit to the previous block.
31